Before you read this you should probably read my original post 5 Reasons why I hate WPF. Also “Qwertie” wrote a nice article detail about his overview of why WPF sucks.

1 – Binding

There is something so nice about setting a button to be enabled or not enabled based on a property in the view. All the enabling and disabling is handled for you (more or less). I find that using MVVM helps in many ways to separate UI logic from UI appearance. Something I’ve always found difficult when writing WinForms in the past.

Using this mechanism and writing a simple implementation of INotifyPropertyChanged means your control availability can be declarative rather than procedural.

public bool ShowFinished
{
    get { return m_ShowFinished; }
    set
    {
        m_ShowFinished = value;
        OnPropertyChanged(() => ShowFinished);
    }
}

Then in your XAML you can do something moderately simple (albeit with arcane syntax)

<BooleanToVisibilityConverter x:Key=”boolToVis” />

<StackPanel Orientation=”Horizontal” Visibility=”{Binding ShowFinished, Mode=OneWay, Converter={StaticResource boolToVis}}”>

Simply set the property to whatever you want in code and the visibility of the stack panel in the UI will show or hide depending on the value. However I have found problems where multiple properties changes in a short space of time don’t seem to actually update until the UI receives some event to prompt a redraw.

2 – Pretty

One thing nobody can deny is that XAML programs can routinely look much prettier with much less work than the same program done via WinForms. This is one of those occasions that are making something hard trivially easy. Say you want to slide in a panel from the side covering the controls and landing with a nice bounce above. No problem.

<EventTrigger RoutedEvent=”ToggleButton.Checked”>

    <EventTrigger.Actions>

        <BeginStoryboard>

            <Storyboard>

                <DoubleAnimation Storyboard.TargetName=”RightSlide”

                                    Storyboard.TargetProperty=”X”

                                    From=”{Binding Path=ActualWidth, ElementName=HiddenSlideOut, Mode=OneWay}”

                                    To=”0″

                                    Duration=”0:0:0.6″>

                    <DoubleAnimation.EasingFunction>

                        <BounceEase EasingMode=”EaseOut” />

                    </DoubleAnimation.EasingFunction>

                </DoubleAnimation>

            </Storyboard>

        </BeginStoryboard>

    </EventTrigger.Actions>

</EventTrigger>

The danger here is (apart from again the arcane syntax) that it’s almost too easy to do fancy graphics. Developers are not known for their restraint when given shiny things to play with – just look at <marquee> or <blink>. The design of a program is best left to a UX professional – step away from the shiny thing.

I may be old fashioned but one of the things I liked about WinForms is some degree of consistency. If something was a button it looked like a button, it rarely looked like a teapot or a spinning cube. Until there is some form on consistency in the new UI I worry that users won’t be able to get the most out of a program because they simply won’t know what is design and what is interface.

3 – Separation of UI and Engine

MVVM is a new thing for me. I was only introduced to design patterns when I started and Red Gate and I still feel I should get more experience writing code using them than I do. I really like the idea behind the MVVM pattern that you can do with XAML. This makes it much easier to test the UI using automated tests and generally inspires you to write cleaner XAML using bindings a lot more extensively.

The gotchas are there for all to see though, try showing a modal dialog box for instance. Or perhaps you’d like to close the application. There are solutions to the issues but none of them yet have the simple elegance of MVVM itself.

4 – CSS style re-use

Using WinForms colour consistency is neigh on impossible to achieve. However with the use of resources in XAML it’s the simplest thing in the world to make sure all your controls share a common colour scheme and even more via the use control templates and decorators. I do think there are many varied ways of doing the same thing and very few “best practices” that were truly elegant.

<Brush x:Key=”SlideColor”>#373737</Brush>

<SolidColorBrush x:Key=”DisabledForegroundBrush” Color=”#888″ />

5 – XML

I’ve a confession to make, my name is Richard Mitchell and I’m an XML addict. Ever since I made extensive use out of XML and XSLT in a previous job I’ve fallen in love (or lust) with it. Now there are those of you who like to point out the failings of XML but almost always in those circumstances you shouldn’t be using XML in the first place for that problem.

The simple rules and fantastic tool support nowadays makes autocompleting even complex XML an absolute breeze and XSD support makes it even better.

Conclusion

Should you try WPF – I say yes. If nothing else it gives you a great new perspective on how UI programming could work, perhaps you’ll stay in the WPF world or use your knowledge in HTML5 (the future is obviously HTML5 no matter how much I personally dislike javascript).